It has been well documented that extensive experience of activities in a domain is necessary to reach very high levels of performance. Deliberate practice is an important element in obtaining the required experience. Unfortunately, deliberate practice is not easy to obtain in medicine due to the intrinsic hazards and complexities of patient care. The use of medical simulators is an alternative to “practicing” on patients and allows skills development without putting patients at risk.
There are a variety of manikin-based, both full-body and partial body, medical simulators available for use in both cognitive and procedural training of clinical personnel. These manikin-based medical simulators can be segmented into three categories, namely, high-fidelity manikin simulators, resuscitation and patient care simulators, and task simulators.
High-fidelity manikin simulators are full-body simulators fitted with sensors and actuators to simulate a patient and react to interventions and therapies. The simulation can be operated by a trainer or utilize physiologic and pharmacologic models to create autonomous reactions. Many of the high-fidelity solutions currently on the market embed most of the support services into the manikin. While this approach allows for a self-contained, highly mobile solution, it tends to result in an expensive solution that is not easily scalable. Special components need to be selected or designed to fit within the manikin, thereby limiting flexibility in the implementation and increasing cost. An example is using an embedded processor in the manikin versus an external laptop. Many users will already have a laptop that can be used for simulation, thus reducing cost. Substituting a different laptop with more processing power is easier than replacing a custom, embedded board if an upgrade is required. In addition, these embedded system components take up valuable space in the manikin that could be used to house modules to provide more training options.
Resuscitation and patient care simulators use a manikin comprised of at least a head and torso up to a full body manikin and are targeted at resuscitation and patient care training. These simulators are most commonly used for procedural training, such as basic life support (BLS) training and advanced life support (ALS) training. Most resuscitation and patient care simulators fall into a mid-range of pricing and cost significantly less than high-fidelity manikin simulators.
The category of task simulators includes partial body models that train for a particular task, procedure, or anatomic region of the body. These simulators are typically used for very specific procedural training. A majority of task simulators are low priced units, but larger, more capable units can be in the mid-range of pricing.
Organizations providing medical training (e.g., hospitals, medical schools, and nursing schools) frequently have a mix of these manikin based simulator products to satisfy training needs which results in significant cost, physical space requirements, and maintenance difficulties. Additionally, there is a large gap in the mid-range of the price and performance curve for medical simulators. Thus, users are often forced to choose between low to mid-priced products focused on procedural training or high-end expensive products focused on cognitive training. There is very little compatibility and interoperability between products, and there is limited modularity and configurability of individual products. For example, physical modularity in current products is typically limited to optional limbs (e.g., IV arm, blood pressure arm, trauma limbs, etc.) or interchangeable genitalia. Software modularity, however, is typical focused on providing training scenarios rather than modular software features. As a result, simulators cannot be interchanged or easily configured for different training needs to provide an open system having both physical and software modularity manufacturers to be interchanged.
Further, most high-fidelity manikin simulators and many resuscitation and patient care simulators contain a central area in the manikin for electronics that includes processing and interfaces for sensors, actuators and other functions. The electronics are designed to have all of the desired and/or anticipated driver circuits and processing requirements. Any circuitry included for future functions typically adds cost and size to the core electronics and may not get utilized. The sensors and actuators that are distributed within the manikin are individually wired to the electronics, resulting in a large wiring harness running to the core electronics. Each actuator or sensor typically needs to be plugged into a specific location in the electronics adding to the complexity. The manikin must also include a power source (e.g., a battery or a power supply) that is capable of powering all of the provided features whether present or not. Therefore, it would be desirable to have a distributed system in the manikin that is highly scalable and flexible to eliminate the restrictions and drawbacks of current manikin systems.
Another common issue in manikin based medical simulators is the generation of body sounds, such as heart, lungs, and bowel sounds. Clinicians listen to these sounds through a stethoscope (called auscultation) to determine if a patient's organs are healthy by evaluating frequency, intensity, duration, number, and quality of sounds. Body sounds have been simulated using a variety of techniques including internal speakers, location-based sound transmission, and remote controlled sound transmission.
Using internal speakers involves placing speakers inside a manikin at locations where sounds need to be heard. This technique allows a standard stethoscope to be used for the simulation. However, this approach has many drawbacks and limitations. For example, sound quality can be poor due to resonances and vibrations in the manikin, and the low-end frequency response can be poor due to limited speaker size. In addition, localizing sounds to a particular area of the manikin can be difficult since sounds travel within the manikin. Further, noise from other system components, such as motors and solenoids, can easily be picked up with the stethoscope.
To overcome the drawbacks and limitations of using internal speakers, techniques, such as location-based sound transmission, have been used to provide a secondary sound transmission based on stethoscope location. With the location-based sound transmission technique, sensors in the manikin are activated or read with a special stethoscope which determines where the stethoscope is placed on the manikin. Based on the location of the stethoscope, the appropriate sound for that location is sent to the special stethoscope using wired or wireless techniques. Alternatively a control signal is sent to the special stethoscope indicating which sound recording to play from a list of sounds stored in the stethoscope. A variety of sensors have been used to determine the location of the stethoscope including magnets and relays, RFID elements, and capacitive signal coupling. However, the resolution of location determination is limited by the location technique used and/or the cost of providing high resolution location. Therefore, this situation can result in poor sound localization. In addition, a special stethoscope must be used that is capable of receiving the transmitted sound or control signals which further increases the cost and complexity of the system.
Remote controlled sound transmission is similar to the location-based sound transmission technique, but location is determined by a trainer rather than an automated technology. A trainer observes where the stethoscope has been located by the trainee and selects the appropriate sound to transmit to the stethoscope on a remote control. Similar to the location-based sound transmission, a special stethoscope must be used that is capable of receiving the transmitted sound or control signals. Additionally, this technique requires constant attention from an instructor and prohibits standalone use by a trainee.
Not only are body sounds important to simulate, but also pulses, breathing and other functions which trainees can observe and feel to simulate interaction with a patient are important for manikin-based simulators. However, the realism and cost of these simulated physiological functions varies greatly depending on the particular implementation.
As just described, a basic function that is important to simulate in a simulator manikin is a patient's pulse. Checking a pulse is one of the easiest ways to determine if a patient's heart is beating, what the heart rate is, and whether the rate is regular or irregular. Pulses have been simulated using a variety of techniques including bulb and tube, air or fluid pressure, and a solenoid driver.
The bulb and tube approach entails running a length of flexible tubing, for example silicone tubing, to the pulse points on a manikin. The tubing is connected to an external bulb that a trainer can squeeze which causes the pressure in the tubing to rise and the tube to stretch causing a pulse along the tube. Being manual, this method is prone to human error and poor repeatability.
The air or fluid pressure technique is similar to the bulb and tube method, however the tubing is pulsed with air from a compressor or fluid from a pump. The pulsations are controlled automatically, thus improving reliability and repeatability. However, the compressor or pump adds significant cost, increases power consumption, and can create undesirable noise. In addition, valves need to be used if the different pulse points need to be control separately, thereby adding to the cost and complexity of the implementation.
A solenoid driver is an alternative to using tubing to create a pulse using a solenoid mechanism. Energizing the solenoid causes a plunger to push on an element that is meant to simulate a section of an artery. However, the resulting pulse tends to feel artificial due to the rigidity of the simulated artery and/or the vertical movement, rather than a flowing and expanding movement.
Another basic function that is important to simulate in a simulator manikin is the breathing motion of the patient, particularly when coupled with a cardiopulmonary resuscitation (CPR) mechanism. The CPR mechanism is typically implemented using a movable or flexible chest plate supported by a compression mechanism (e.g., a spring, shock absorber and hinged support). The compression mechanism fills much of the chest cavity which inhibits other training modules, such a heart and lungs models, from being used. This design also produces chest motion during compression that is not natural and limits the way that breath motion can be simulated. Breath motion in such a system is typically done by inflating a bladder that moves the chest plate. The resulting motion is not natural since the sides of the rib cage do not move as occurs during actual breathing.
Thus, none of the above described techniques produce a reliable, cost-effective and automatic means of creating realistic body sounds, pulses, and breathing motions, More generally, the preceding examples serve to illustrate that there is a substantial body of open-source, publicly available material to provide the mathematical models and parameters describing physiological behaviors. Similarly, there are numerous equation solver engines which can process those equations and generate simple tabular and graphical outputs. However, what is missing is a common platform that allows integration and interoperability between models, tools that allow users to easily modify and test models within an integrated system, and integration with flexible and scalable output devices.
Thus, it would be beneficial to provide an integrated, low-cost simulation platform where the advantages of cognitive and procedural training can be merged and where users can customize the system to suit a wide variety of applications from simple to complex. It would be beneficial to have a highly scalable, modular medical simulation system that can be easily configured by users for their specific needs with different types of physical and/or software modules. A modular solution allows specific features to be combined for an application rather than users paying for features that are not needed or going without features that are highly desirable, or being limited to just procedural or just cognitive training. Such a system also allows users to buy and support a single simulation platform rather than having to buy multiple, incompatible products. In addition, it would be beneficial for a base product to be created that can receive modules in order to reduce the initial cost and effort of manikin implementation and allows the manikin system to migrate with changing training needs. Lastly, it would be beneficial to provide an open system so that modules could be provided by different vendors, thus allowing the development cost to be spread out across vendors and allowing users to buy the best in class offerings for a particular application.